Module 10 Closure
Spring 2006
Prepared by Greg Kinney

Most meaningful items

• The chapter describes a method for both crashing and leveling a project. I knew that it was possible to do so, but had no knowledge on how to go about it or what I should considered when deciding to crash and/or level a project. (This was very beneficial)

• As Dr. Perkins pointed out, this chapter is very clear and understandable up to about 9-6. I was using leveling prior to this chapter and now understand it even better.

• The most useful thing I learned in this module was how to crash a project using Microsoft Project.  The term crash is almost a misnomer.  If I said I “crashed” my car, you would think I did something that I’m going to regret.  But if I said I “crashed” the project, that really means I expedited certain activities within the project in order to move the completion date ahead of schedule.  Of course, there are costs associated with everything (including the crashing of a project).  It’s important for the project manager to understand the cost-duration history of that project and verify the benefit to moving the completion date ahead of schedule.  I guess this would be likened unto cost-benefit analysis.  Understanding the weight and priority of various resources has a direct affect on the final outcome of a project.  Being aware of possible tradeoffs during the life of the project is also important when it comes to leveling resources and streamlining the project.  In short, this module was very similar to module nine (chapter 8) and dealt with the other side of the project.  Chapter 8 was scheduling and chapter 9 was resources.  The two sides are like legs.  You can’t get very far on just one.  You need both of them to be working right to make any real progress. 

• This chapter has clarified the difference between crash and fast-tracking, which both accelerate a project’s completion. Crash refers to the expediting of critical path items of a project, while fast-tracking overlaps design and construction.   Instructor replies:  Yes – although if you crash a project, you may have to modify tasks that would be normally outside the critical path.  Don’t forget that if you only crash the critical path, then other project paths then may become critical.

• Clearest thing: The Procedure to find crashing costs and Cost-Duration history is a straight-forward task. Logical procedure of looking at the critical path first and then evaluating all possible ways a crash can be made makes sense.

• The concept of resource leveling is very interesting to me.  I do find it amazing that along with scheduling everything and making sure all the parts and pieces show up on time, a PM needs to shuffle everything around to make sure his resources are as level as he can make it.  This sounds really complicated and I’m glad the book touched a little bit on the software end of this.      

• Comment: "The muddiest" was the Heuristic method, it seemed to me that this was a hard method to use to help the constrained resource allocation problem.
Comment:  The modeling is explained quickly and poorly. Hope I don’t see that again.
Comment:  [The muddiest was] about 9.7 on.  Very ‘in the clouds’, not much that I found interesting or relevant. 

• Comment:  Section 9.5 on Constrained Resource Scheduling states that, “Far to often, PMs are surprised by resource constraints.” This statement seems generalized, wouldn’t experienced PMs consider constrained resources when they develop a schedule. I can see where an inexperienced PM might be surprised by resource constraints which they are unfamiliar with, however, do experienced PMs get caught by constrained resources? 

Instructor’s reply:  The answer is an unqualified yes.  I believe there are three basic reasons why.  The first is that experienced PMs have a lot of processes to manage concurrently, particularly if they are managing multiple projects.  Even though they actually know they need to secure resources, they may be distracted and not think of what to do until they are caught flat-footed later on. 

The second reason is that there is typically a lack of understanding at the company level.  In a multi-project organization, there are a lot of people working on a lot of projects.  This means that there is a big picture that very few people have, and fewer still (if any) understand the micro-details of required resources and how that compares with resources that are going to be available.  They don’t have those details until they are bumping up against resource constraints, such as skilled labor, bedspace, rolling stock, etc., and by that time, schedules have to slide.  Of course, what is at fault here in this case is lack of adequate advance planning effort at a company level.

The final reason is related to the first and the second.  The PMs themselves are paid to be “worry-warts” and to be pushy.  If they aren’t, you’ll often see a lack of followthrough on items that later prove critical.  One of the things that they need to be most concerned about is resources.  They need to ask the hard questions that cause the company to look harder at what will be required.  In other words, they have to get focused on this issue and then prod the company to develop its near-term and medium-term resource plans. 

Only when the information gets developed does it become clear what the resource constraints will be.  Not that the crystal ball is perfect: it isn’t.  But it is necessary to do that level of planning and projection.  It doesn’t happen without work and without prodding.

• Comment:  The muddiest thing in this module had to do with heuristic methods related to critical path networks.  There were so many different priority rules listed.  It was unclear as to what rule to use at a particular time.  I can understand “as soon as possible” but why and how would you use “most successors”.  I’m sure there is an appropriate place and time to use one rule over another but at this point, I’m a little uncertain.

Instructor’s reply:  I haven’t used that heuristic approach, but I believe the main reason to concentrate on “most successors” is that tasks having the most successors can be regarded as most leveraging in reducing the overall duration requirements of the network.  We’re potentially interested in compressing the duration of the job as a whole, not just the critical path (because the critical path could shift once you compress certain tasks).  Thus, looking at “most successors” could be helpful in assuring that schedule compression will propagate throughout the network.

• Comment:  Also, what is the main difference between the heuristic and the optimization approach?  I think that optimization only works with simple type projects and projects that are somewhat logical and flow in that manner.  On the other hand, heuristics deal with project that are complex and illogical in terms of flow and layout.  Is my distinction between the two close enough or is there a better way of distinguishing between the two methods? 

Instructor’s reply:  The heuristic approach includes rules of thumb and rule-based observations.  For example, we have a homework problem that requires the student to identify what paths to partially crash.  You can solve that by noticing what tasks have the lowest cost slopes, and then configuring the ways in which you get to a 10 day partially crashed schedule.  This is essentially a cut-and-try method:  it employs the logical rule that the tasks to focus on are the ones having the lowest cost impact first.  But in solving that problem, you haven’t proven (unless you explore by enumeration all possible alternatives) that there isn’t some other tactic giving you the same result. 

If, on the other hand, you employ an optimization approach (also known as an “operations research,” “management science” or “mathematical programming” approach), you can show what the least cost approach.  (This is covered in the Operations Research class.)  Excel includes an add-in, called Solver, that is handy for this kind of thing.  Essentially, you find the minimum of something (in this case, cost) given a set of constraints that can be mathematically described. 

There is a problem with that kind of approach, in that it’s often hard to formulate the mathematics, even for simple problems.  At least it’s harder than it’s worth, even though the advent of Solver made the solutions vastly easier.

• Comment:  What factors determine the costs of running late in a typical project? 

Instructor’s reply:  Primarily, in my experience, it is the cost of extra labor.  If a project is running late, you may have to hire extra people, or keep them on longer than expected.  You’re tying up resources that could be used more profitably elsewhere.  Also, there is the cost of equipment rentals running on longer than expected, overtime costs, and in some cases liquidated damages (which most courts say can only be legitimate costs of a delay, not a penalty clause).  In some organizations, any project that stays alive gets assigned accruals that support project administrative general expenses.  Plus, there can be extra interest expenses from extensions of construction loans.